Personally, I prefer a simple shell script over conditional steps or dedicated actions, because shell scripts can be easily replicated in a local environment and are generally more easily understandable.

I refactored the validation jobs in 788baa1 since I also agree those could be simpler.

On a personal level, I prefer the conditionals on the jobs or actions. The workflow execution graph is calculated before it is sent to the runner and conditionals that evaluate to false are skipped. When everything is in a shell script you have to be more careful what behaviors should lead to job failure and explicitly have it fail.

I'm fine either way. Let me know if the refactor is ok.

We've seen this numerous times, where we want to replicate the runner's behaviour and debug or test a workflow locally, e.g. after a refactoring or a maintenance change. If everything is a job with conditional execution, as opposed to a simple script in a single job, there is zero chance of doing that, and ACT only gets you so far. Maybe I'm just old and like bash scripting.

Let's get this merged as-is so as not to block the PR.

Generally speaking, I would be very cautious when adding GH actions, because we are effectively introducing undebuggable foreign code, that you have no control over.

this looks complicated plus it will be evaluated for every PR closed. given that we're following a sort-of gitflow approach, why don't we release on the release branch and at the end we merge it back to main later? this will simplify things a little.

Yes, it will be evaluated for every merged PR on main but it won't run because of the condition. And since this is a job-level conditional, github will just skip its execution and not throw any error (btw, that is the reason why I prefer job/action level conditionals vs everything script).

Like such.

If we release from the release branch we can't create the tag from it, otherwise the release branch cannot be deleted.

I wouldn't say it looks complicated. Its actually very readable. It's just a veeeery long line 😅

well, the tag can be created after the release branch has been merged into main. I think that's the typical gitflow approach

I don't think I got your point then, sorry.
Your suggestion is to change the trigger of the release workflow to be the push on the release branch?

Either having this workflow to run when a PR is closed on a release branch or making it manual as for the bugfix version.
At the end of the release we could merge back to main if ref_name starts with release and snapshot version can be bumped.
The more the release and bugfix processes are similar, the easier will be to maintain them

The workflow is being triggered when a PR is closed on a release branch. If we really want to avoid the workflow to be evalutated on every closed PR to main, we can make it manual only.